Deck.gl已原生支持3d-tiles和i3s，比Cesium更值得选择~

2020年应该是GIS可视化市场剧烈变化的一年，其中就包括基于游戏引擎的可视化解决方案对传统的Web GL 3D可视化方案的冲击，估计目前大部分的GIS公司都开始All in GameEngine了，但是很显然基于Game Engine和基于WebGL 的3D可视化方案之间并不存在非此即彼的关系，也不存在Game Engine是3D GIS可视化2.0的说法，这二者在我看来是并列的，针对不同的使用场景选择不同的解决方案，甚至是融合的方案。

虽然基于WebGL的3D可视化解决方案已经出现了一段时间，但是我们需要承认，目前的WebGL解决方案还是处在很不成熟的阶段，这也导致在大场景和渲染效果方面具有绝对优势，同时成熟度也很高的基于游戏引擎的解决方案在众多赛道中跑了出来。

但是在这一轮的市场混战和教育过程中，有些业主单位也逐渐明白了目前看似“热闹”的游戏引擎方案是怎么回事了，在大屏可视化方面游戏引擎有明显的优势，但是在业务支持的场景上还存在比较大的问题。从第一性的角度来看，更广泛的分发和更开放的融合才是“一张图”最核心的价值。

从这个意义上来说，Web3D存在更广泛的使用场景，是一种更重要的存在，在选择上自然需要两手都要抓，但是到底哪只手更硬就需要结合自己在业务和未来场景上的判断了。

在Web3D方面，其实目前在市面上出现了不少基于Cesium定制的产品出现，在性能和可视化效果上都不错，当然这是建立在团队本身有较高的研发能力的基础上，同时公司在核心技术上也有长期投入的打算。但是目前市面上的大多数公司的核心业务还是面向行业提供解决方案，业务能力在这些公司是核心能力，在技术上更多的还是选择拿来主义或者是采购商业平台，同时目前原生的Cesium质量其实还不够理想，伸起手来又怕被打脸。

在WebGL这个方向上，其实大家也都在等待一个更好的解决方案出现。恰好我最近又关注了一下之前看的比较多的可视化框架deck.gl，发现他在examples上释放了一些新的3D案例出来，还是挺让人兴奋的。

这款框架大家应该都比较熟悉，但是不知道对这款框架保持持续跟进的多不多，其实这个框架初期在众多的框架中还不存在很明显的优势，他提供的基础能力很多其他框架也都提供了，而且这种框架的上手难度其实有点大，起码在源代码的修改层面上，React就可以吓退很多人。

如果说dek.gl之前的主要精力是放在二维专题数据的可视化方面，是一个半成品三维可视化框架，在地位上很类似Mapbox GL，但是目前的deck.gl可以称之为了一个完整的三维可视化框架了，主要原因就是deck.gl已经加入了对3d-tiles和i3s数据源的支持，而且在性能上有着非常不错的表现，如下是deck.gl官方释放的一个大场景三维模型的加载和调度的效果，在我的只配置了集成集成显卡的机器上都可以很流畅的运行和加载。

基于上面的一些测试，这让我们必须要回过头去仔细审视一下这个雄心勃勃的WebGL框架：

1、deck.gl拥有更高的开源质量，我相信大部分使用过Cesium的人，都需要花不少精力去理解Cesium的代码风格，从工程角度而言完全基于ES6语法的deck.gl在代码可读性和扩展性方面都有着很大的优势，同时代码是由uber的可视化团队进行维护，虽然发版本很慢，但是也一直保持着代码的持续更新。

另外一点需要考虑的就是主创团队是否足够的慷慨，首先在商业模式上，Analytical Graphics的主要营收还是基于Cesium展开的，这样必然会分出社区版本和企业服务版本，但是deck.gl背后的Uber的主营业务还是网约车，其他的应该是属于技术支持部分，所以在开源上的投入会更为慷慨和纯粹。

2、deck.gl具备更广泛的兼容性，deck.gl在架构设计上有一个非常有特点的地方就是将数据解析部分剥离出来，做成了独立的项目loader.gl，用于适配目前市面上大多数的开放格式，其中就包括了3d-tiles和i3s，从而让deck.gl专注于渲染部分，在3dtiles支持的案例上，虽然在案例上官方只给出了海量点云场景的案例介绍，但是从代码上来看deck.gl已经增加了对batch 3d model的支持，所以本质上已经是具备了完整的功能，同时我相信在调度性能上应该会做的比cesium本身做的更好，起码在i3s的调度上性能还是不错的。

基于上面的一些分析以及目前deck.gl在框架上的规划，是时候需要把deck.gl这个框架重新拾起来了~